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Abstract 

We present practical poisoning and name-server block- 
ing attacks on standard DNS resolvers, by off-path, 
spoofing adversaries. Our attacks exploit large DNS 
responses that cause IP fragmentation; such long re- 
sponses are increasingly common, mainly due to the use 
ofDNSSEC. 

In common scenarios, where DNSSEC is partially or 
incorrectly deployed, our poisoning attacks allow 'com- 
plete' domain hijacking. When DNSSEC is fully de- 
ployed, attacker can force use of fake name server; we 
show exploits of this allowing off-path traffic analy- 
sis and covert channel. When using NSEC3 opt-out, 
attacker can also create fake subdomains, circumvent- 
ing same origin restrictions. Our attacks circumvent 
resolver-side defenses, e.g., port randomisation, IP ran- 
domisation and query randomisation. 

The (new) name server (NS) blocking attacks force re- 
solver to use specific name server. This attack allows 
Degradation of Service, traffic-analysis and covert chan- 
nel, and also facilitates DNS poisoning. 

We validated the attacks using standard resolver soft- 
ware and standard DNS name servers and zones, e.g., 
org. 

1 Introduction 

The correctness and availability of information in the Do- 
main Name System are crucial for the operation of the 
Internet. In particular, DNS poisoning is a significant 
threat to Internet security, and can be used for phishing, 
credentials stealing (e.g., XSS), sending spam and phish- 
ing emails, eavesdropping, and more. Due to its wide 
use and universal availability, the DNS is also abused in 
other ways for different goals, including Denial of Ser- 
vice, fast-flux, covert botnet communication, and more. 

Most DNS (poisoning and other) attacks 'in the wild', 
as well as most research, considered an off-path adver- 



sary that is able to send spoofed packets (but not to inter- 
cept, modify or block packets). The most well known 
is Kaminsky's DNS poisoning attack [21 1, which was 
exceedingly effective against many resolvers at the time 
(2008). Kaminsky's attack, and most other known DNS 
poisoning attacks, allows the attacker to cause resolvers 
to provide incorrect (poisoned) responses to DNS queries 
of the clients, and thereby 'hijack' a domain name. We 
refer to this type of attack as Domain-hijacking DNS poi- 
soning, to distinguish between it and two other variants 
of DNS poisoning, to which we also present off -path at- 
tacks; more below (and see Table[T|. 

The increased awareness to the risks of DNS poison- 
ing, following the publication of Kaminsky's attack, was 
one of the factors helping to speed-up the (long-overdue) 
adoption of the DNSSEC standard |2}|4). DNSSEC uses 
digital signatures to prevent poisoning of the DNS re- 
sponses, and is hence secure even against man-in-the- 
middle (MitM) adversaries. DNSSEC had a long and 
thorough design and evaluation process, and its secu- 
rity is based on extensive evaluation by many experts, 
as well as on results of formal analysis, e.g., by Bau and 
Mitchell p). (There are also alternate proposals for se- 
curity against MitM, e.g., DNS Curve Q). 

However, deployment of DNSSEC is challenging and 
would take considerable time. Hence, as a more im- 
mediate response to Kaminsky's attack, resolvers were 
rapidly 'patched' to protect against it, mostly following 
RFC5452 [19). The 'patches' include source port ran- 
domisation, source and destination IP randomisation, 
and query randomisation: case toggling ('0x20 encod- 
ing', (9)) and addition of a random prefix to queries (30). 

These 'patches' increase the entropy of 'unpre- 
dictable' fields copied from DNS requests to DNS re- 
sponses, and hence are trivially insecure against MitM 
attackers. However, these patches are considered 'best 
practice', since they are believed to provide sufficient se- 
curity against off-path attackers (which is considered as 
sufficient defenses for many systems). 
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We show that, under common scenarios - which seem 
likely to become even more common in the future, an 
off-path attacker can efficiently circumvent all of these 
mechanisms. Namely, an off-path attacker can perform 
effective 'domain-hijacking' DNS poisoning attack, cir- 
cumventing all the 'patches', and with even better effi- 
ciency than Kaminsky's poisoning technique. However, 
our domain-hijacking attack fails when DNSSEC is cor- 
rectly and fully deployed. This attack works in scenarios 
where DNSSEC is partially or incorrectly deployed, such 
as permissive resolvers and islands of trust; currently, 
such scenarios are rather common. 

We also present three other attacks, which apply even 
if DNSSEC is correctly and universally deployed: 

Subdomain Injection, is a poisoning attack which 
causes resolvers to accept, cache and provide to clients 
a mapping for a non-existing (child) domain, of a 
DNS SEC -protected parent domain. As |5| observed, 
when the parent zone supports NSEC3 opt-out, the at- 
tacker can create fake (non-existing) sub-domains; this 
can lead to attacks on Same Origin Policy such as XSS, 
phishing and cookie stealing. We show how an off-path 
attacker can achieve the same effect. 

Name Server (NS) Hijacking, is a poisoning at- 
tack which causes resolvers to cache and use incorrect 
name servers for a DNSSEC-protected domain, typically, 
pointing them to name servers belonging to the attacker. 
We show how this attack provides new, efficient off -path 
methods for traffic analysis, covert channels and Denial 
of Service; notice the attack and its applications are vi- 
able, even if DNSSEC is universally and correctly de- 
ployed, since the delegation NS and A resource records 
(RRs) are not signed. 

Name Server (NS) Blocking, allows the attacker to 
force resolvers to query name servers of his choice, and 
stop using other name servers, by corrupting fragmented 
responses from those name servers. This is not a poison- 
ing attack, since it does not involve a resolver accepting 
fake resource records. In fact, one application of this at- 
tack is to facilitate poisoning, by causing resolvers to use 
specific name servers, possibly known to be vulnerable; 
this provides an effective mechanism to deploy the attack 
of 1 32 1, which was, so far, considered impractical. Under 
certain situations, this attack can also be used for off -path 
Degradation of Service and traffic analysis. 

We summarise all our attacks, with their requirements, 
in Table [T] The requirements are explained in Section |2j 
for now, it suffices to mention that they all reflect com- 
mon situations in the current DNS, many of which are not 
expected to change, even if DNSSEC is fully, universally 



and correctly deployed. The main exception is attacks 
which require partial or incorrect DNSSEC deployment; 
however, not only is this requirement currently often sat- 
isfied, but it is also required only for the 'domain hijack- 
ing' attack. 

In fact, ironically, the use of DNSSEC is often what 
provides necessary requirements for our attacks to work. 
Specifically, all of our attacks require 'Fragmentable 
zone', implying fragmented DNS responses; and three of 
the attacks require 'Poisonable zone ', implying that the 
second fragment contains complete resource record(s), 
from the 'authority' and/or 'additional' sections. More 
details on the requirements are presented within. 

DNSSEC requires long resource records (RRs) which 
results in long DNS responses. Long DNS responses 
(i.e., above 512 byte) require support of the EDNS exten- 
sion mechanism, (35), and often fragmented when sent 
over UDP, since their size exceeds the path MTU. It is ex- 
actly this fragmentation that facilitates our attacks; e.g., 
we show that off-path attackers can often replace the sec- 
ond fragment of a packet, resulting in a seemingly-valid, 
yet fake, DNS response, or 'merely' causing corruption 
of the DNS response. 

Fragmentation is known to be problematic or 'harm- 
ful', mainly due to the negative impact on performance; 
see the seminal paper of Kent and Mogul [23 1. As a 
result, fragmentation is usually avoided, e.g., by use of 
path MTU discovery [28 , 29], mainly for connection- 
based transport protocol (TCP). However, DNS traffic is 
usually sent over UDP; while several significant name 
servers, e.g., com, edu, send long responses over TCP, 
this may not be a good long-term solution, since the use 
of TCP results in significant overhead. 

Related Work. 

Our work builds upon previous disclosures of vulnera- 
bilities due to the design or implementations of the frag- 
mentation mechanism; we next mention few of the most 
relevant. Zalewski [37) suggested that it may be possi- 
ble to spoof a non-first fragment of a (fragmented) TCP 
packet. However, using such non-first-fragment injec- 
tions to TCP packets seems challenging. Furthermore, 
currently almost all TCP implementations use path MTU 
discovery J2"8"||29") and avoid fragmentation. 

Several vulnerabilities related to IP fragmentation, and 
specifically to predictable fragment identifiers (IP-ID) 
values, are covered in |jT4j|T5j. Later, predictable IP- 
ID values were shown p2) to allow interception and in- 
jection of fragments, as well as dropping of fragmented 
packets. While for our purposes, a simple, randomised 
modification of fragments suffices, we modify the tech- 
nique from [ 12] to improve the efficiency of the attack in 
some scenarios; details within. 
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Table 1: Our attacks and requirements. 



Attacker Capabilities. 

The required attacker capabilities include an arbitrary 
off-path, spoofing-only adversary, that controls a 'pup- 
pet', i.e., malicious (but sandboxed) script which can 
query the resolver; see Figure [T] 
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Resolver 




Fi gure 1 : Simplified network topology and attacker capabilities. The 
spoofing attacker uses a puppet to invoke the query. 



Contributions. 

Incremental DNSSEC Deployment is Vulnerable We 

show that incremental deployment of DNSSEC is 
risky, and exposes resolvers to cache poisoning at- 
tacks. We present techniques which allow efficient 
and effective Kaminsky-style [22] cache poisoning 
attacks, using off-path spoofing adversaries. Our 
techniques (exploiting fragmentation) allow to 
circumvent the entropy (randomisation of query, 
source port and IP) in DNS responses, as those 
entropy fields remain in the first fragment. This 
exact technique of circumventing the entropy fields 
allows us to revive the Kaminsky attack, and to 
replace the authentic records in a DNS response 
with spoofed records. 

Subdomain Injection We show that an off-path at- 
tacker can perform the attack that was believed to 
be feasible for MitM. 

Unsigned Delegation We suggest attacks exploiting un- 
signed NS and A delegation records, breach- 



ing privacy and anonymity, and inflicting de- 
nial/degradation of service. 

Name Server (NS) Blocking We introduce the name 
server blocking technique, which allows an attacker 
to force the resolver to stop using a particular name 
server, and eventually, to query a name server of at- 
tacker's choice, e.g., a compromised name server, 
when resolvers strictly follow RFC 4697 J25|. 



We performed an experimental evaluation of our attacks 
against standard resolver software and issuing queries 
to real TLD name servers, such as org, and against 
the name server of the domain of our university, i.e., 
sec.cs.biu.ac.il. 

Organisation. 

In Section [2] we outline the assumptions which are re- 
quired for our attacks and in Section 3.1 we provide the 
basic mechanisms for our attacks. 



Then, in Section |3T2] 
we show techniques for name server blocking, and in 
Section|4]we present the poisoning attacks. We then con- 
clude and propose defenses in Section [5] 

2 Attacks Requirements 

In this section we describe the requirements of the differ- 
ent attacks that we introduce in this work. See Table[T]for 
the requirements of each attack. Below, we dedicate one 
subsection to the 'Fragmentable zone' and 'Poisonable 
zone' requirements, and another one to the 'Permissive 
or Island' requirement. We initiate with a brief descrip- 
tion of three technical requirements: IP-ID, NSEC3 opt- 
out and RFC 4697. 

2.1 Technical Requirements 

The IP-ID requirement is that attackers have 'reasonable' 
probability of success in guessing the IP-ID in the re- 
sponses from the name servers. In IPv4, the IP-ID field 
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consists of only 16 bits; considering that fragment re- 
assembly can usually hold a significant number of frag- 
ments for specific senders, typically at least 64, this im- 
plies a good success probability even if attacker just 
guesses the IP-ID values. Furthermore, many systems, 
and in particular most name servers, authoritative for ma- 
jor TLD zones, e.g., mil, use operating systems where IP- 
ID is generated sequentially, either globally (for all des- 
tinations) or with per-destination counters. In both cases, 
we can significantly improve the probability for a correct 
match. We optimised the IP-ID prediction, in the per- 
destination case, by adapting the technique of fl2} to be 
used with resolver. Note that in IPv6, it is harder to pre- 
dict the IP-ID, since it is 32 bits and is sent only in frag- 
mented traffic; however, IPv6 specifically recommends 
the use of sequential IP-ID, and hence can be guessed 
with good chance of success. The bottom line is that the 
IP-ID requirement is almost always satisfied. 

The NSEC3 opt-out requirement is that the zone 
uses NSEC3 DNSSEC record with opt-out option | |26| . 
This allows attackers to create fake (non-existing) sub- 
domains, and thereby facilitate XSS, phishing and cookie 
stealing attacks. Sub-domain injection attack was pro- 
posed in J5), that carried it out by a MitM attacker. In 
fact, Q, also suggested that the attack could be carried 
out by an off-path attacker, assuming that only the trans- 
action ID in DNS packets is randomised. However, this 
assumption does not hold for most DNS resolvers, as 
they (at the very least) support source port randomisa- 
tion. In Section l4~2l we show that such an attack can be 
effectively carried out by an off-path attacker, that does 
not intercept and inspect packets, and against patched 
DNS resolvers, i.e., supporting source port randomisa- 
tion, IP randomisation and DNS query randomisation. 

In spite of the publication of this potential abuse by 
MitM |5|, NSEC3 opt-out is still widely used, and often 
even recommended, since it improves performance (esp. 
as long as DNSSEC is deployed only in small fraction of 
the domains). 

The RFC 4697 requirement is that resolvers adhere 
to (one of) the recommendations in RFC 4697 p5j[36) , 
specifically, that a resolver will refrain from sending 
queries to a name server after (few) failures, i.e., timeout 
queries, within a predefined time interval, and to lame 
name servers, i.e., those that provide DNS responses 
where (some of) the DNSSEC records, e.g., signatures, 
are missing or corrupted. We show in Section |3.2| that 
this allows an attacker to cause resolvers to stop using 
specific name server(s), facilitating poisoning attacks, as 
well as other attacks, including off-path traffic analysis 
and covert channel attacks. We validated this behaviour 
in popular and standard DNS resolvers, see Section |3~2| 



2.2 Fragmentable Zone and Poisonable 
Zone Requirements 

We now describe our two fragmentation requirements: 
'Fragmentable zone' and 'Poisonable zone'. The 'Frag- 
mentable zone' requirement is necesssary to all of our 
attacks, and essentially amounts to the ability of the at- 
tacker to cause fragmentation of a response from a name 
server. As can be seen in Figure [2] long second frag- 
ments are rather common, and responses are fragmented 
from most top level domains (which deploy DNSSEC), 
e.g., in the gov top-level domain, which is the top-level 
domain with maximal adoption of DNSSEC so far. 

Note that fragmentation can also occur even if the 
resolver does not deploy DNSSEC, e.g., it relays a 
query for a DNSKEY from the client, or due to other 
types of records which can be long, e.g., different TXT 
records, and/or when fragmentation occurs at relatively 
low packet length I, due to success in sending fake ICMP 



fragmentation-required alerts (see Section 2.2 1 
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Figure 2: Length of ANY and NXDOMAIN responses of gov do- 
mains. Domains taken from [10] 

The 'Poisonable zone' requirement is necessary for 
our poisoning attacks, and requires that at least one com- 
plete record is present in the second fragment so that the 
attacker can modify the second fragment and replace the 
authentic resource record with a spoofed one, which gets 
accepted and cached by the resolver. Details follow. 

The ability to cause the required fragmentation de- 
pends both on the records in the zone file, as well as 
on the properties of the name server (including the route 
from the name server to the resolver). In particular, frag- 
mentation typically depends on the smallest MTU en- 
route on the path from the name server to the resolver; 
packets larger than 1500 bytes will normally be frag- 
mented. The attacker may also sometimes be able to 
'trick' the name server into fragmenting (even) shorter 
packets before sending them. The attacker can inflict 
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fragmentation by sending a spoofed ICMP 'fragmenta- 
tion needed' packet, similar to attacks in fl3) . Let / 
denote the size of packets, above which attacker can 
cause fragmentation - the minimal MTU along the path, 
or the minimal length that the attacker can 'force' the 
name server to use by issuing fake ICMP fragmentation- 
needed alerts. 

In principle, name servers could be configured to 
never allow fragmentation of responses, by sending re- 
sponse packets of length up to (some bound of) I bytes 
with the DF (do not fragment) bit set, and send longer 
responses only via TCP, relying on TCP's path MTU 
discovery mechanism. However, the use of TCP for 
DNS requests and responses has significant performance 
penalty, in addition to the overhead and complexity of 
handling fragmentation-required ICMP alerts received 
due to sending packets with the DF set, which reach 
a network whose MTU is smaller than the packet size. 
Hence, we do not expect name servers to send packets 
with DF bit set (and indeed have not seen this behavior, 
e.g., com, edu). 

Note that for the 'Fragmentable zone' requirement to 
hold, any fragmentation suffices, e.g., of 1 byte, and there 
is no requirement on the contents or length of the sec- 
ond fragments. Hence, we only require existence of a 
response whose length is greater than I. 

A 'Poisonable zone' requirement is a stronger assump- 
tion, since it also implies that the attacker is able to in- 
clude a (fake) resource record in the response, such that 
the response - and in particular the fake record - would 
pass validation at the resolver and get cached. This re- 
quires that the second fragment is predictabl^] (to allow 
attacker to avoid corrupting the checksum), and that it 
contains at least one modifiable record - typically, an 
NS record in the authority section, or an A ('glue') 
record in the additional section. The challenge here 
is mainly to find queries which will result in second frag- 
ments containing the necessary record(s) which the at- 
tacker will replace with its own. 

Caching and Time to Live (TTL). The DNS re- 
solvers will not issue queries at all, if there is a corre- 
sponding cached response. The TTL field of each DNS 
resource record indicates how long it may be cached by 
resolvers. 

The majority of TTLs of DNS records range between 
one hour to one day, [20]. However, many records have 
very low or even zero TTLs, e.g., records of content dis- 
tribution networks (CDNs). Furthermore, some queries, 
most notably for non-existent domain, always or usu- 
ally would not be in cache. In fact issuing queries for 
non-existent domain is similar to Kaminsky style attack, 
and allows to initiate the attack as frequently as required 

' The (off-path) attacker can query the victim name server itself to 
select the query whose response it will poison. 



since the attacker simply prepends a new random string 
to the query. We demonstrated attacks exploiting frag- 
mented non-existent domain^\or no-datc^\ [ 1 j, DNSSEC- 
enabled responses. We also found that often DNSSEC 
public verification key (DNSKEY) records, which typ- 
ically exceed MTU and get fragmented, have relatively 
short TTL e.g., 15 minutes in org domain; they also of- 
ten indicate short expiration time in the signatures. 

Hence, caching would usually not prevent the attack, 
and the expiration time of some record from the cache 
can be anticipated by the attacker; there may be some 
impact on length of attack and possibly on its commu- 
nication costs too, but this would not make the attack 
infeasible. Usually, successful poisoning happens within 
reasonable time. 

2.3 'Permissive or Island' requirement 

The 'Permissive or Island' requirement is that DNSSEC 
validation is either not used or is not correctly used, and 
thus ignored by the resolver; 'Island' means that not 
all the zones from the root to the target zone deploy 
DNSSEC correctly, and 'Permissive' means that resolver 
does not fail even DNSSEC-enabled responses do not 
validate. In either of this cases, DNSSEC does not of- 
fer protection, although deployed. 




unprotected protected ■ island ■ 



Figure 3: The DNSSEC deployment, in the list from (To) of 1500 
subdomains of gov. 



Permissive Resolvers. A permissive resolver is one 
that supports DNSSEC, however, ignores DNSSEC val- 
idation failures, e.g., if the signatures are missing or in- 
valid; Unbound DNS resolver has an explicit 'permis- 
sive' mode to support such operation. Obviously, for 

2 Non-existent domain DNS response contains an error bit in the 
DNS header, i.e., RCODE='name error', and indicates that the re- 
quested name does not exists in the zone file. 

3 No data DNS response does not contain an error, i.e., RCODE='no 
error' , and it means that the requested name exists in the zone file but 
does not have the type requested in the DNS query. 
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such resolvers, DNSSEC does not provide added secu- 
rity; yet, there appears to be a significant number of such 
resolvers |8|16| . apparently due to concerns about loss of 
connectivity due to interoperability and other problems 
upon enforcing DNSSEC. Such implementors deploy 
DNSSEC incorrectly or possibly via an 'incremental de- 
ployment', aiming to preserve DNS functionality with 
intermediate Internet devices, e.g., firewalls, and legacy 
resolvers which may discard DNSSEC enabled DNS re- 
sponses or strip DNSSEC signatures. This approach ap- 
parently assumes that permissive use of DNSSEC can 
provide evidence on whether the network can deploy 
DNSSEC fully without problems or not, while not harm- 
ing their security; unfortunately, this is not the case and 
such resolvers are open to poisoning. 



Island of Security. When the parent zone returns an 
NSEC or NSEC3 (indicating that the child does not sup- 
port DNSSEC), while the child does, the resolver can- 
not establish a 'chain-of-trust' to the target zone and thus 
cannot validate the DNSKEY of the zone. This holds for 
many second level domains, e.g., children of gov TLD 
(Figure|3]l, and even for some TLDs, e.g., mil. As a re- 
sult, the resolver falls back to non-validating mode, and 
ignores the signatures in a DNS response. 



3 Fragment Overwriting and NS-Blocking 

In this section, we present the Name Server blocking (NS- 
blocking) attack, allowing attackers to cause resolvers 
to avoid querying a name server. This attack requires 
much weaker assumptions than the poisoning attacks, 
Section [4] and only assumes that the responses get frag- 
mented. Both NS-blocking and the poisoning attacks, 
rely on Fragment Overwriting. 

Fragment Overwriting, explained next, allows attack- 
ers to modify fragmented packets. In Section 3.2 



we 



explain how fragment overwriting allows an attacker to 
cause standard-conforming resolvers to avoid a particular 
name server, i.e., to perform NS-blocking. Then, in Sec- 



tion 3.3 we discuss potential exploits of NS-blocking. 



3.1 Fragment Overwriting 

We now present a simple technique, allowing an attacker 
to replace (overwrite) second fragments of (fragmented) 
IP packets, in particular, of DNS responses sent to the 
resolver; this basic technique is applied in all of our at- 
tacks. 

Suppose the original packet has payload x, and, after 
fragmentation, it is sent as two IP packets yi,yi- Then, 



the defragmentation process, running at the resolve^jon 
inputs < y i,y2 > reproduces x. 

To overwrite the second fragment, the attacker sends a 
fake second fragment y' 2 so that it arrives at the defrag- 
mentation module before the authentic fragments ?/i , y 2 
of the DNS response. The defragmentation mechanism 
in the IP layer will cache y' 2 , in anticipation of the rest 
of the packet. By default, an unmatched fragment is kept 
in the cache for 30 seconds or so, hence, 'planting' such 
fake fragments is easy; we now explain how the attacker 
can ensure a match with the original packet. Note that 
it is easy to adjust this technique for the (less common) 
case where fragments are sent in a reverse order: attacker 
removes the authentic second fragment y 2 from the re- 
assembly buffer by sending an arbitrary y[ (whose val- 
idation fields match those of the y 2 ), and the rest is the 
same as above. 

According to 1 18 31] the fragments of a datagram are 
associated with each other by their protocol number, the 
value in their IP-ID field, and by the source/destination 
IP address pair. Thus both the first authentic fragment 
yi and the second spoofed fragment y' 2 must have the 
same destination IP address (of the resolver that sent the 
query), the same source IP address (of the responding 
DNS server), the same protocol field (UDP) and the same 
fragment identifier (IP-ID). In addition, the spoofed sec- 
ond fragment should have the correct offset (as in the 
authentic second fragment). The fragment reassembly 
process, applied to the pair < y\,y 2 >, returns either a 
failure or a different packet x' ^ x. 

Matching most of these parameters is not difficult. In 
particular, path MTU changes infrequently, and can be 
found by attacker easily, e.g., by trace-route. In many 
scenarios, the resolver has a single, known IP address; 
zones typically have 6 IP addresses on average. The at- 
tacker may sometimes also have some knowledge on the 
likely name servers since the server selection algorithms 
of many resolvers can be predicted [36], e.g., based on 
latency, and may even use our attacks to disable some 
name servers; in the worst case, the attacker can launch 
the attack for each name server in parallel. In this work 
we show techniques which often allow the attacker to 
simply block the name servers of its choice. 

It remains to ensure a match between the value of the 
fragment identifier (IP-ID) field in the fake fragment y 2 , 
and the IP-ID in the authentic fragment y\ of the orig- 
inal response x. There are several possible options for 
IP-ID prediction, depending on the version of the IP pro- 
tocol (IPv4 or IPv6), the method that the name server's 
OS uses to select IP-IDs, and on the receiver implemen- 
tation. 

In the most common case the communication is over 



4 Alternatively, defragmentation may happen and at intermediate de- 
vice such as a firewall or NAT; there is no impact on the attack. 
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IPv4, where the IP-ID field is 16 bits; and the host per- 
forming the defragmentation process, i.e., the resolver or 
firewall, has cache of 64 (or more) fragments per partic- 
ular <source IP, destination IP, protocol> combination; 
note that when more than 64 fragments (for the same tu- 
ple) arrive, the oldest fragment is evicted from cache and 
is replaced with the new one. Assuming that the attacker 
has no knowledge on the process according to which 
the IP-ID is incremented, and assuming the IP-ID in the 
packet and in the fake fragment are selected indepen- 
dently, it suffices for the attacker to send 64 spoofed sec- 
ond fragments, to ensure success probability of roughly 
1/1000 of replacing the second fragment of a packet in 
a single attempt. A much better probability of success 
(as we discuss next) can typically be achieved, however, 
even this attack can be sufficiently efficient for many sce- 
narios. 

Most systems select the IP-ID sequentially. Of these, 
many use a single counter for all destinations (globally- 
sequential), as in Windows and by default in FreeBSD. 
Other systems, e.g., Linux, use per-destination IP-ID 
counters. In both of these cases, the attacker can ef- 
ficiently predict the IP-ID, achieving high probability 
of success (certainly compared to 1/1000). In particu- 
lar, for globally-incrementing IP-ID, which appears to 
be more widely used, e.g., mil, the attacker can simply 
learn the current value, and the rate of propagation, by 
querying the name server directly. The technique we use 
to achieve improved success probability in the case of 
per-destination IP-ID, is an improvement of the methods 
of p2) . These techniques ensure feasibility of the attack 
even for most implementations of IPv6, in spite of its use 
of 32-bits IP-ID field. 

3.2 Name-Server Blocking 

In this subsection, we present the NS-blocking attack, 
allowing an off-path attacker to dissuade resolvers from 
querying particular name server(s); this can have multi- 
ple goals, including denial/degradation of service, traffic 
analysis and more (see next subsection). 

As indicated in Table [T] the NS-blocking attack has 
two main requirements: the ability of the attacker to gen- 
erate a DNS query from the resolver, that will result in 
fragmented response from the 'victim' name server; and 
that the resolver follows a behaviour recommended in 
RFC 4697 E5][36), namely, of avoiding a name server if 
there are two or more failures within some time interval 
(the time interval depends on the resolver implementa- 
tion). We first describe how the attacker is able to block 
responses to a particular query, which does not rely on 
the behaviour recommended in (25j . 

To block responses to a query from a particular name 
server to the resolver, the attacker needs to send an ar- 



bitrary fake second fragment y' 2 with the anticipated IP- 
ID and other parameters, to match a legitimate response, 
as described above. The reassembly process using the 
legitimate first packet and the fake second fragment usu- 
ally fails, and both fragments are silently dropped, by the 
UDP layer or by the DNS resolver itself, due to incor- 
rect checksum. The resolver will resend the query after 
a timeout, but the timeout periods are known to the at- 
tacker, who can easily send appropriate fake fragments 
to cause loss of each of the responses, until the resolver 
gives up. The number of attempted retransmissions de- 
pends on the number of name servers that the zone uses; 
if the zone uses one name server, the resolver gives up 
in about 5 to 7 retransmissions, e.g., Bind9 after 7 time- 
outs, and Unbound 1.4.10 after 5 timeouts, if the zone 
uses more name servers then after one to two timeouts 
the resolver queries the next name server. 

We show how to apply this technique, in order to per- 
form NS-blocking, i.e., block a specific name server, in- 
stead of blocking just one particular packet. For this, 
we need the assumption that the resolver avoids querying 
unresponsive name servers, as per the recommendations 
in 1 25 36 j. We exploit the fact that when the target name 
server is not responsive, i.e., two or few queries times- 
out, the resolver does not sencQany more queries to it. 

The attack is illustrated in Figure |4] The idea is for 
the attacker to send a spoofed fragment, e.g., one byte 
long, which ruins the DNS response from the specific IP 
address. After repeating the attack few times (depending 
on the resolver software), e.g., twice in every 15 minute 
interval for Unbound, the resolver marks the name server 
(or rather the IP of the name server) as non-responsive 
and does not send queries to it for the specified interval 
of time which depends on the resolver implementation. 

It is important to notice, that with most resolvers, NS- 
blocking is effective against a specific name server IP, 
and not limited to a specific domain. Namely, we can use 
NS-blocking to dissuade a resolver from using a specific 
name server, e.g., at IP address 38.103.2.1, using queries 
(with fragmented responses) to one domain isi-sns.info, 
and as a result the resolver will also avoid this name 
server for all the other domains which that server serves, 
e.g., paypal.com. This can be very useful, as name 
servers often host multiple domains, and some of these 
may use DNSSEC (and have fragmented responses), or 
be owned (or corrupted) by the attacker (who can put 
some other record with fragmented response), while oth- 
ers may only have short (unfragmented) responses, in ad- 
dition, some domains are much less frequently queried, 



5 Resolvers may send periodical probes, to detect when the target 
server becomes responsive, however, the period is so long that we can 
ignore it, e.g., for the Unbound name server, the period is 15 minutes. 
A similar behaviour of avoiding non-responsive name servers was ob- 
served by [36| in PowerDNS and WindowsDNS. 
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Figure 4: The Name-Server blocking attacks. 



e.g., info, than popular domains, e.g., paypal.com, that 
use the same name server, allowing to match the IP-ID 
with little effort; e.g., p2[ show that a typical domain 
name depends on 46 name servers on average which also 
serve other domains. 

As illustrated in Figure |4] we performed the attack 
against a 404.gov domain, whose non-existing domain 
responses exceed 1500 bytes and thus get fragmented en- 
route. This phase, of forcing the resolver to use a specific 
IP, requires a puppet, i.e., a script confined in a browser, 
which issues DNS requests via the local caching DNS 
resolver, at IP 1.2.3.4 in Figure |4] 

In steps 1 and 2 the puppet coordinates with the 
attacker and issues a DNS request for $123. 404. gov 
(where $123 is a random prefix). In steps 3 and 4, the 
spoofer sends a forged second fragment, for all the possi- 
ble name servers (i.e., a total of 2 spoofed fragments) ex- 
cept one which the attacker wants the resolver to use for 
its queries during the poisoning phase; the 404.gov do- 
main has three name servers. This ensures that only one 
IP address will result in a valid response, and the other 
two result in a malformed DNS packets. The spoofed 
second fragment is incorrect, and contains a single arbi- 
trary byte (in addition to headers). In step 5, the spoofed 
second fragment is reconstructed with the authentic first 
fragment resulting in a malformed DNS packet which 
leaves the fragments reassembly buffer. This malformed 
DNS response is then discarded by the resolver, and the 
IP of the name server is markeqj as 'non-responsive'. 
When the authentic second fragment arrives, it does not 
have a match and is discarded after a timeout. As a re- 
sult the resolver does not receive the response, and after 
a timeout it resends the DNS request to the next DNS 
server, step 6. The same procedure applies here, and the 
response is discarded. In step 9 a valid response arrives 

6 In reality the resolver marks the server as 'non-responsive' after 
two unsuccessful responses; this is handled by sending two spoofed 
fragments with consecutive IP-ID in IP headers. 



from IP 162.138.183.11. This way, by wrecking the re- 
sponses from all name servers except one, we forced the 
resolver to direct all its queries for 404.gov domain to 
162.138.183.11. 

The IP-ID allocation algorithm does not have a signif- 
icant impact on our attacks against such resolvers (e.g., 
Unbound), since 'misses', i.e., valid responses arriving 
to the resolver from some IP, do not prevent the attack; 
e.g., two failed (timed-out) queries suffice for Unbound 
to mark the server as non-responsive for 15 minute inter- 
val. 

The Wireshark capture, in Figure|5] that was run on the 
resolver, demonstrates the experimental evalutation, i.e., 
the DNS packets entering/leaving the network card of the 
resolver. During the course of the experiment the puppet 
issued 6000 querie^jto the resolver. The spoofer initiates 
the attack by sending three spoofed fragments to each IP 
address except 162.138.183.11. For simplicity, the cap- 
ture presents only the packets exchanged between the re- 
solver and the name server of 404.gov at 162.138.191.23 
(by adjusting a corresponding filter in wireshark); the 
complete capture contains queries/responses from other 
name servers too. Packets numbered 18-20 are the forged 
fragments sent by the spoofer, with sequentially incre- 
menting IP-IDs. Then puppet triggers a DNS request, 
packet 29. The response from the name server contains 
two fragments, packets 33 and 34. The first fragment 
is reassembled with spoofed fragment 18, resulting in a 
malformed packet which is discarded by the resolver. 

The second fragment is discarded after a timeout. In 
packet 48 the resolver requests a public verification key 
of the 404.gov zone. The response contains three frag- 
ments 49-51; the first fragment is reconstructed with the 
spoofed fragment in packet 20, which also results in a 

7 Note that our goal was to test the behaviour of the resolver, and 
to check the frequency of the queries to non-responsive servers; in real 
attack, once the IP-ID is known it is sufficient to issue two queries to 
mark the server as non-responsive. 
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49 19:28:58.018788 162.138.191.23 132.70.6.119 

50 19:28:50.018836 162.138.191.23 132.70.6.119 

51 19 : 28 : 50 .018850 162. 138 . 191 .23 132 . 70 . 6 . 119 



Protocol Info 



Fragmented IP protocol !proto=UDP exll, off=1480, ID=2cc8] [Reassembled In #33] 
Fragmented IP protocol (proto=U[IP 6x11, off =1480, I0=2cc9) 

Fragmented IP protocol jproto=UDP 6x11, off=1480, ID=2cca] [Reassembled in #49] 
Standard query response, No sued name [Half armed Packet] 

Fragmented IP protocol iproto=UDP 6x11. off=148B, ID=2ccBi 



Standard quer^ response DNSKEY DNSKEY DNSKEY DNSKEY DNSKEY DNSKEY[Halformed Packet] 

Fragmented IP protocol Iproto=UDP 6x11, off=1480, I0=2cca) 
Fragmented IP protocol tproto=UDP 6x11, off=2960, I0=2cca) 



Fi glire 5^ The wireshark capture of the attack, presenting only the packets exchanged between the name server 162.183.191.23 and the resolver. As can be observed, 
after two malformed responses the resolver refrains from sending further queries to that name server for 15 minutes. Fragmented packets are coloured in white, DNS 
requests in black, and reassembled DNS fragments in blue. 



malformed DNS response and is discarded. Note that 
this request, in packet 48, was sent at 19:28. Based 
on our tests it can be seen that when Unbound encoun- 
ters a timeout twice for the same destination IP, it stops 
sending further packets to that destination for 15 min- 
utes. Indeed, the next packet that is sent to that IP is 
packet number 6848, at time 19:43. The same scenario 
was observed with IP 162.138.191.11. The queries be- 
tween 19:28 and 19:43 were sent only to 162.138.183.11, 
avoiding 162.138.191.11 and 162.183.191.23. Note that 
even if some of the responses (between packets 33 and 
49) were valid and accepted by resolver, e.g., if they were 
not fragmented, it did not make a difference, and two 
timed-out responses in a 15 minute interval were suffi- 
cient for Unbound to stop querying those IP addresses; 
this fact shows that the success probability of the attack 
does not depend on the IP-ID selection mechanism. 

3.3 NS-Blocking: Applications 

NS -blocking is rarely a goal by itself; more often, it can 
serve as a mechanism for other goals. We discuss three 
such goals: facilitation of DNS poisoning; degradation 
of service, and traffic analysis. 

Facilitate DNS poisoning In J32| , Ramasubramanian 
and Sirer conducted a survey showing that a typical do- 
main name depends on 46 servers on average, and names 
belonging to countries depend on a few hundred servers. 
They note that compromising a server can lead to domain 
hijacks and postulate that it is possible to hijack 30% of 
the domains in Yahoo and DMOZ.org directories; DNS 
servers are known to have vulnerabilities [11, 24 ] . How- 
ever, |32 1 did not suggest a technique which can be used 
to force a resolver to query a specific name server. NS- 
blocking can provide exactly the necessary mechanism. 

Also note that NS -blocking can assist in other DNS 
cache poisoning attacks, including these in the next sec- 
tion of this paper, as it allows the attacker to reduce the 
number of servers that the resolver can query, possibly to 
only one. 



Off-path Degradation of Service By blocking 'good' 
name servers, an attacker can cause resolvers to send 
their traffic to specific, 'bad' name servers. In particu- 
lar, resolvers may resort to name servers with very high 
latency, causing unnecessary delays. Note that the zone 
administrators often deploy techniques to distribute the 
load between several physical servers sharing the same 
IP, e.g., using load balancing or Anycast [ [17) . Typically 
not all the name servers of a domain deploy such optimi- 
sations, e.g., 6 out of 13 root servers, [27]. Our technique 
allows the attacker to block those servers and to 'force' 
the resolver to query a name server which does not sup- 
port such load balancing. 

Off-path Traffic Analysis and Covert Channel 

Many names servers provide side-channels allowing an 
attacker to learn or estimate the rate of requests handled 
by the server. In particular, one simple and effective side- 
channel is the IP -ID used by the name server. 

We next show how an off-path attacker can use this 
side channel, in conjunction with NS-blocking, to esti- 
mate (analyse) the rate of requests from some resolver 
r, to a particular domain foo.bar. NS-blocking can fa- 
cilitate such off-path traffic analysis in several ways; as 
we later explain, this side-channel can even allow covert 
communication (between a bot using the resolver, and an 
attacker which is not controlling the name server). 

First consider the case that one (or more) of the name 
servers of foo.bar, say ns.foo.bar, is using globally- 
incrementing IP-IDs (this is common). By using NS- 
blocking, we can direct all or most of the DNS re- 
quests from r to ns.foo.bar; by periodically querying 
ns.foo.bar, the attacker can measure the rate of progress 
of the IP-ID (and hence of responses sent by ns.foo.bar). 
To further improve the measurement, the adversary may 
use NS-blocking to cause other major resolvers to avoid 
using ns.foo.bar. 

This mechanism also allows off-path covert channel, 
between an agent, say a bot b, which can use the resolver 
r, and an off-path attacker o, which can make queries to 
the name server ns.foo.bar. The bot can, e.g., encode in- 



9 



formation by signaling via the queries to ns.foo.bar (or 
possibly, signaling using distinct queries to several do- 
mains, each mapped to a specific, distinct name server). 
The attacker can communicate to the bot by signaling via 
loss of DNS responses. 

The traffic analysis attack is applicable also if none of 
the name servers of foo.bar use globally-incrementing 
IP-ID, provided at least one of them, say ns.foo.bar, uses 
per- destination incrementing IP-ID. In this case, the at- 
tacker will also need the ability to use the resolver r, e.g., 
via a puppet (malware such as script, in a sandbox). At- 
tacker will use the puppet to keep track of the IP-ID used 
by ns.foo.bar to send packets to r. 

4 DNS Response Poisoning 

The main idea behind our DNS cache poisoning attacks 
is to apply Second-fragment Overwriting technique to 
change the content of a DNS response by replacing au- 
thentic resource records (RRs) with spoofed A or NS 
RRs either for the existing domain or for a new subdo- 
main. Specifically, the off-path attacker triggers a DNS 
request to some victim domain, e.g., using a puppet (ma- 
licious script confined in a browser), and then spoofs 
the second fragment. Depending on the section (of the 
DNS response) which the second fragment contains, i.e., 
authority or additional, the attacker replaces au- 
thentic records with his fake record^] 

The main difference between the attacks is related to 
the two intertwined issues: (1) frequency at which the 
attack can be repeated, and (2) the queries which the at- 
tacker can request. Both these issues depend on the free- 
dom of the attacker over the (suitable) queries which it 
can request. 

NXDOMAIN or No-Data Responses. To evade 
caching of the resolver the attacker can issue DNS re- 
quests for 'non-existing domain names', i.e., responses 
containing an RCODE with name error, or responses in- 
dicating that the domain name exists but with a different 
type, i.e., with 'no data no error' responses. Such re- 
sponses exist in every domain. We found that domains 
that use NSEC3 (which is currently the majority of the 
domains) to indicate nxdomain (and no data) responses, 
to be most suitable for our attacks as those responses 
get fragmented in the authority section, such that 
the second fragment contains at least one complete RR 
(not including the EDNS RR). This technique is simi- 
lar to Kamisky attack, as it allows the attacker to repeat 
the attack as frequently as required, by selecting a differ- 

8 The attacker can also replace the RRs in the answer section, e.g., 
if it can issue DNS requests for ANY type RR, and if the DNSSEC is 
either incorrectly, or not at all, deployed. 



ent random name (prepended to the real domain name) 
in each query. However, nxdomain responses may not 
always get fragmented, e.g., if the zone does not use 
NSEC3. 

'Existing Domain' Responses. If the attacker triggers 
the attack with queries for existing domain names (with 
a non-zero TTL) that get fragmented, e.g., responses to 
DNSKEY, then it can trigger the attack only if the record 
is not in cache. If the attack fails the first time, it has 
to wait till the record expires from cache, i.e., the TTL 
reaches or sinature expires. 

Records with zero TTL, e.g., used for CDN networks, 
can be requested repeatedly, thus allowing to launch 
the attack as frequently as required, since they are not 
cached. Such DNS responses with (zero TTL) records in 
the answer section also contain (among others) NS and 
A records (in authority and additional sections 
respectively) with a cache-able TTL, which the attacker 
can replace. However, the zero TTL records may not ex- 
ist in every domain, and in particular, may not exist in a 
domain which the attacker wishes to poison. 

Thus the typically query choice of the attacker is be- 
tween 'nxdomain/no-data' or 'exiting domain' (with a 
non-zero TTL). 

Poisoning the Cache. Inserting spoofed records into 
the cache is not straight forward, and merely changing 
the records in a DNS response will not necessarily result 
in resolver accepting and (then) caching them. In par- 
ticular, the forged DNS response must comply with the 
caching (and other) conditions which the resolvers im- 
pose on DNS responses: the forged packet p' must be a 
valid DNS response; the 'poisonous' resource record r' 
must be valid for the specific response and section of the 
response; and the resolver must cache r'. 

The choice of forged DNS records, which we ap- 
ply when modifying the DNS response, and semantics 
and values of each field in a DNS record, essentially 
follow the known rules for DNS cache poisoning and 
were investigated and studied (most notably) by Kamin- 
sky J22) and Son and Shmatikov [33] , and by Bau and 
Mitchell (5j for DNSSEC enabled DNS responses. 

4.1 Domain Hijacking 

Domain hijacking can be performed when the 'Permis- 
sive or Island' requirement is satisfied in tandem with 
'Poisonable zone', i.e., either the resolver is permissive 
or zone is an island of security and there is at least one 
RR in the second fragment. In this case the attacker can 
replace the RR(s) in the authentic second fragment of a 
DNS response with (spoofed) NS or A RR(s) pointing at 
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his name server; the TTL in those spoofed RRs has to 
match the TTL of the other RRs in that RRset. 

Note that our domain hijacking techniques (below) 
trivially apply to (fragmented) DNS responses which 
are not protected with DNSSEC, we show such attack, 
exploiting queries for TXT RRs and the correspond- 
ing responses that get fragmented in full paper (the at- 
tack course is essentially similar to the attacks presented 
next). 

We tested the domain hijacking attack in two scenar- 
ios (as elaborated above): (1) nxdomain/no-data and (2) 
existing domain. The 'nxdomain/no-data' (NSEC33) re- 
sponse is often fragmented in the authority section, 
and the additional section contains ar0EDNS RR. 
This allows replacing the authority records in the 
second fragment with fake NS RRs; we show this at- 
tack in Section |4. 1.1| replacing an NSEC3 record with 
a spoofed NS record in the authority section in re- 
sponse to a request for some non-exiting domain within 
sec.CS.biu.ac.il, i.e., the (DNSSEC-enabled) domain of 
the security group of the computer science department 
within our university.. The 'existing domain' response, 
e.g., DNSKEY or TXT, is also often fragmented. Such 
responses typically contain records in the additional 
section too, and allow changing the IP of name server 
with IP of the attacker. We show this attack in Sec- 
tion gT2] 

4.1.1 Injecting NS RR to NSEC3 Response 

Typically, responses of type 'non-existing domain (nxdo- 
main) name error' or 'no data no error', in domains that 
support NSEC3, are of size between 1700 to 2000 bytes 
on average, and when fragmented, at least one record 
from the authority section appears in the second frag- 
ment. This allows the attacker to replace the authen- 
tic NSEC3 or RRSIG RR(s) with a NS RR for a new 
name server; Figure [6] If the response does not contain 
any other NS RRs then the attacker can set an arbitrary 
high TTL, e.g., 6 days, to ensure that his RR stays in 
cache even when the authentic NS RRs for that domain 
expire. The attacker triggers a DNS request (via a pup- 
pet) and synchronises (steps 1 and 2, Figure |6j. Then 
(step 3) the attacker sends a spoofed second fragment 
containing an NS RR for domain sec.CS.biu.ac.il. This 
spoofed fragment is combined with the authetic first frag- 
ment (step 3) and enters the cache; the authentic second 
fragment is discarded after a timeout (step 5). Note that 
the attacker can provide any arbitrary NS RR, in par- 
ticular, one that is not in the same domain as the vic- 
tim; in this attack we spoofed the response with name 




Figure 6: Poisoning an nxdomain (or no data) response, by replacing 
the NSEC3 RR with an NS RR. 



for a new NS RR, i.e., ams.sec.CS.biu.ac.il, in our do- 
main, i.e., sec.CS.biu.ac.il, for testing purposes to ob- 
serve that the subsequent queries of the resolver to do- 
main sec.cs.biu.ac.il are sent to ams.sec.cs.biu.ac.il 
and responses get cached. To find the IP of the new NS 
the resolver initiates a request for the A RR, and receives 
and caches the IP supplied by the attacker (who controls 
that name server). 

The wireshark capture of the resulting poisoned DNS 
response is in Figure [7] The authentic fragment con- 
tained part of the RRSIG and two complete records, 
i.e., NSEC3 and a corresponding RRSIG. The spoofed 
fragment contained the authentic part of the RRSIG, 
spanning the first and second fragments, and two fake 
NS records which replaced the authentic NSEC3 and 
RRSIG. Note that since the RRSIG (as well as NSEC3) 
are much larger than NS RRs, the attacker has to pad the 
packet (with zeros) to the required length; the checksum 
is adjusted in the padded area after the EDNS RR. For a 
comparison, see the authentic DNS response in Figure [8] 



Query with a ~"| 
^ random prefix J 

12J4wnw^ec.cs.biu. ac. il: type A, class IN 

sec.cs.biu.ac.il: type S0A, class IN, mname rs.sec.cs.biu.ac.il 
sec.cs.biu.ac.il: type RRSIG , class IN 
V6RIC3ME4B93H04HFS8SIIiOUlP58PR6. 




V6RI03ME4B93H04HFS8SIILQU1P58PR6 . sec 
VFNBK0H55GUDUG4HAU1F8NKUNDTEG18V .sec 
VFNBKOH55GQDuG4HA01F8NKUNDTEGlGV.5ec 



+ J44Mu65:FN2K9TUlCGM3 01DA5FE71 VUBO . 
+ J 44MD65FN2K9TU 1CGHJ QLDA5FE71VUB0 .sec.CS.biU.ac.il: 

AQtlitioria I records 



cs . biu.ac.il 



cs . biu.ac.il 



type NSEC3 
type RRSIG 
type NSEC3 
type RRSIG 




type NSEC3 , 
type RRSIG, class IN 



This is not a requirement, and according to (11 an A RR can ap- 
pear in the additional section too. In this case, the attacker simply 
replaces the A RR (instead of NS). 



Figure 8: An authentic nxdomain response for domain 

sec.cs.biu.ac.il. 



4.1.2 Injecting A RR to DNSKEY Response 

When the second fragment contains at least one complete 
record (excluding the EDNS RR) in the additional 
section, the attacker can replace the IP address in the 
fragment with a spoofed IP. In this attack we spoof the 
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random prefix 



Questions : 
Answer RRs 
Authority RRs 
Additional RRs 
Q ueries 

+ | 123wwwl sec.cs.biu.ac.il: type A, class IN 
Authoritative nameservers 
+ sec.cs.biu.ac.il: type SOA, class IN, mnai 
+ sec.cs.biu.ac.il: type RRSIG, class IN 

+ V6RID3HE4B93H04HFS8SIILQUlP58PR6.sec.cs.biL.ac.il: type NSEC3 
+ V6RIQ3HE4B93HQ4HF585IILQUlP58PR6.sec.CS.hiL.ac.il: type RR5IG 
+ 2AGEPQTQBUADUT6KIDK68H4M89UFQHBF.sec.CS.hiu.ac.il: type N5EC3 
+ 2AGEP 0TGEUADUT6KIDK6BH4N89UFGHBF.sec. cs.biu.ac.il: type RR5IG 



Padding to the 
required length 
with zeros 



rs.sec.cs.biu.ac.il 




class IN 
class IN 
class IN 
class IN 



+ sec.cs.biu.ac.il: type MS, class IN, ns ams.sec.ci.biu.ac.il 

+ www.sec.cs.biu.ac.il: type NS, class IN, ns ams.sec.cs.biu.ac.il 
Additional records 
- <Root>: type OPT 



Tspoofed RRs 



04eQ 37 b4 19 5b 86 e5 a0 70 0b 8d 71 ca 7c c2 90 cfl 

04-fQ 23 00 02 09 01 00 00 90 64 00 06 03 61 6d 73 C0 

13 03 77 77 77 C0 13 00 02 00 01 00 00 00 64 00 

06 03 61 6d 73 CB 13 00 00 29 10 00 00 00 80 00 

0520 |09 00 00 09 00 00 00 00 00 00 90 00 00 90 00 00 

0550 
570 
0530 
0590 
05a0 
05b0 
05c 
05d0 

05f0 
0600 



Figure 7: Poisoning an nxdomain (or no data) response for domain sec.CS.biu.ac.il, by replacing the NSEC3 RR with an NS RR. 



IP for the name server of org domain, in a DNS response 
for a DNSKEY of org domain. 

In Figure [9] the resolver issues a DNS request for 
the DNSKEY of org; this is an indirect way to trig- 
ger a query, i.e., the resolver asks for the DNSKEY of 
some domain automatically, when the DNSKEY expires 
from cache, or when it needs to validate records for that 
domain, e.g., to be able to validate an A record or a 
non-existing domain (NSEC3) record; an attacker may 
also be able to cause a resolver, which does not support 
DNS SEC, to issue such a query, by sending an appropri- 
ate request to the resolver. This query type is useful if 
the response to an nxdomain query is not fragmented. 
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Figure 9: DNS poisoning attack of name server IP of org domain. 
The resolver issues a query for a DNSKEY (e.g., when it expires from 
cache, 15 minutes for org), and the spoofer sends a poisoned second 
fragment containing the forged entries of org. The query for DNSKEY 
of org can also be triggered indirectly by issuing a query for non- 
existing (or for some other) domain within org. 

The annotated screen caption of the attack in 
Figure [9] is illustrated in Figure 10 presents the out- 
come of the attack. The first line (122) contains the 
'forged second fragment'; this fragment is kept in 
the defragmentation cache of the resolver, waiting 
for a matching first fragment (i.e., with the same 
set of (source IP=199 . 249 . 112 . 1, dest 
IP=132 . 70 . 6 . 202, fragment ID=7c6e, 
protocol=UDP ) ). In the next line (133), the resolver 
sends the DNS query to the name server. 

Next line (134) is the first fragment of authentic re- 
sponse to the query, sent by the name server of org (at IP 



199.249.112.1). This response matches the fake second 
fragment already in the defragmentation cache, hence it 
appears as a complete DNS response packet. The con- 
tents of this packet are described in the lower panes; in 
particular, see the two forged resource records in the ad- 
ditional section, which contain incorrect (adversarial) IP 
addresses for two of the name servers of the org domain. 

Finally, notice that the authentic second fragment, 
received in line 135, has no matching first fragment 
(since the one received was already reassembled with the 
spoofed second fragment). Hence, it is entered into the 
defragmentation cache, where it is likely to remain until 
discarded (typically, after maximal lifetime of about 30 
seconds). 



4.2 Subdomain Injection 

The delegation records, NS (name server) and A (IP ad- 
dress), located in authority and additional sec- 
tions, are not signed, |3J. This allows the attacker to 
change the IP address (in the additional section) of 
the name server of some victim domain, to its own ad- 
dress, or to add a new name server (in authority sec- 
tion) for the victim domain. Such NS and A records are 
usually cached and used, for queries to the specified do- 
main; see [33 1 . At this point, the attacker managed to 
cause queries for the victim subdomain to be sent to a 
machine controlled by the attacker. 

This vulnerability, of redirecting DNSSEC enabled 
DNS requests to malicious server by a man-in-the- 
middle, was pointed out by Bernstein (6), yet with- 
out a specific application for such an exploit. Bau and 
Mitchell, 1 5 J, refute Bernstein's claim of this being a vul- 
nerability, by proving that it does not enable a man-in- 
the-middle attacker any additional capabilities, and con- 
clude that it does not pose a significant threat. Indeed, 
not signing the delegation records does not break the de- 
sign requirements defined for DNSSEC, |3|. However, 
it exposes to NS Hijacking (leading to a range of other 
attacks), Section [43] and to subdomain injection (as we 
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Fi gure 10: A Wireshark capture presenting the DNS packets in a DNS cache poisoning attack exploiting fragmented DNS responses by spoofing 
the second fragment of the response to the DNSKEY query; messages exhange diagram corresponding to this caption is in Figure|5] 



discuss next). 

Resource records in the answer section of DNSSEC- 
enabled domains are signed, hence, if the resolver per- 
forms strict validation of DNSSEC, it should not ac- 
cept unsigned records in the answer section. How- 
ever since the delegation records in the authority 
and additional sections are not signed, the attacker 
can create a new subdomain, e.g., secure.bank.com 
under bank. com, by creating an NS record (in the 
authority section) for the new subdomain se- 
cure. bank. com mapping it to the name server which 
the attacker controls. This attack is only applicable to 
DNSSEC protected domains that use NSEC3 opt-out: 
the attacker may be able to use legitimate NSEC3 re- 
sponses, e.g., for non-existing sub-domain, or other type 
responses, e.g., DNSKEY, and turn them into what ap- 
pears to be a legitimate referral to an unprotected sub- 
domain; this can be used for phishing attacks. Fur- 
thermore, as (5) show, domains which deploy NSEC3 
opt-out records are vulnerable to browser cookie theft 
by a man-in-the-middle attacker, as they allow the at- 
tacker to insert insecure delegations into DNS responses. 
This is in contrast to the recommendations in |26] which 
suggest that NSEC3 opt-out does not pose a significant 
threat. Bau and Mitchell performed the attack with a 
man-in-the-middle attacker, using our techniques an off- 
path spoofing attacker can perpetrate such attacks, see 
Figure [7] 

The attack is similar to the attack in Section |4T.l| thus 



to save space, we performed the addition of a new subdo- 
main as part of the name server hijacking attack, see Fig- 
ure[7] The record: WWW.sec.CS.biu.ac.il is a new (non- 
existing) subdomain under sec.CS.biu.ac.il and it points 
at the name server ams.sec.CS.biu.ac.il controlled by 
the attacker. 

4.3 NS Hijacking 

Using 'server blocking' the attacker can 'fix' the target 
name server. If the attacker compromised that server then 
the attack is very damaging. Server fixing can be useful 
for other attacks too, e.g., to degrade efficiency (if the 
target server is the slowest), for traffic analysis, e.g., if 
the attacker has man-in-the-middle capabilities but only 
on the path to that 'fixed' server, but not to other servers 
for that domain. 

Server fixing in tandem with DNS poisoning can allow 
the attacker to force the resolver to use a malicious name 
server which the attacker controls, we call this 'NS hi- 
jacking'. This attack is most relevant when DNSSEC is 
properly deployed. If the DNSSEC is not deployed cor- 
rectly, then the attacker can simply hijack the domain. 
The attack is combined of two phases: (1) poisoning the 
A (or respectively NS) record in the DNS response (by 
changing the authentic IP to the IP controlled by the at- 
tacker), then (2) applying server blocking by ruining re- 
sponses from all other name servers so that the resolver 
marks those authentic servers as non-responsive. 

Note that phase (2), i.e., server blocking, is not es- 



13 



sential and the poisoning attack by itself implies NS hi- 
jacking. This is due to the fact that the TTL of the poi- 
soned RR is higher than the TTL of the records cached 
from previous responses, therefore, once those authentic 
records expire from cache, the resolver will not request 
them and will use the poisoned cached NS RR. 

As a result of this attack the resolver will only query 
the server of the attacker (as it is the only one that re- 
sponds). However, the attacker cannot produce valid sig- 
natures for the records that it returns, and therefore it 
responds to resolver's queries with records that are not 
protected with DNSSEC. This attack has the 'cache-or- 
crash' effect, i.e., the resolver will either cache those re- 
sponses, or will timeout and not be able to provide re- 
sponses (since this is the only name server that the re- 
solver has for the victim domain). The response depends 
on the specific resolver in question, e.g., Unbound 1.4.1 
in permissive mode caches such responses, while Bind9 
times-out and does not. 

5 Conclusions and Defenses 

We showed how an off-path attacker can efficiently ex- 
ploit fragmented DNS responses to poison DNS caches. 
Most DNS responses are short, and hence not frag- 
mented; our attacks exploit DNSSEC records, which of- 
ten result in fragmented responses. 

We also showed that fragmented responses can be ex- 
ploited by off-path attackers to force the resolvers to 
query name servers of attacker's choice. 

The attacks are effective against valid implementation 
of the DNS and IP specifications; furthermore, we have 
confirmed effectiveness against several domains, using 
real network scenarios and common resolvers (Unbound 
1.4.1 and Bind9). 

We want to caution against drawing the conclusion 
that DNSSEC should not be used. In fact, the best de- 
fense is to apply DNSSEC correctly in all resolvers and 
domains (without using NSEC3 opt-out); this will cer- 
tainly prevent many of our poisoning attacks, and even 
defend against more powerful Man-in-the-Middle adver- 
saries. However, incremental DNSSEC deployment is 
vulnerable to our cache poisoning attacks, and complete 
adoption of DNSSEC may take considerable time, since 
it depends on adoption by both name server and resolver. 
Furthermore, this will not prevent the server blocking 
attacks. Hence, we also discuss some other defenses, 
which can be utilised by only one of the parties (unilat- 
erally), and can also prevent the DNS response blocking 
attacks. 

The vulnerability which allowed us to launch the poi- 
soning attacks against recursive resolvers, is due to the 
fact that the resolver advertises a large EDNS buffer, 
which is usually larger than the MTU, e.g., 1500 bytes. 



Although support of large DNS responses is critical to fa- 
cilitate DNSSEC enabled DNS responses, or public-key 
certificates [34], such long responses can be (temporar- 
ily) sent over TCR using path MTU discovery and avoid- 
ing fragmentation - unfortunately, at significant perfor- 
mance costs. Another countermeasure, possible at re- 
solver, name server or even at intermediate gateway (fire- 
wall), is to set a maximal EDNS buffer value to at most 
1500, or even less, to avoid fragmentation. In fact, re- 
solvers may implement a simple protocol similar to path 
MTU discovery, then set the value of the EDNS buffer 
accordingly to the minimal MTU en route between the 
resolver and the DNS server. When sending responses, 
the name server should also set the DF bit in the IP 
header to 1, i.e., do not fragment. 

Another short-term defense, which administrators of 
resolvers can apply, is to reduce the maximal number of 
fragments cached; e.g., currently 64 by default in Linux 
(per (source IP , dest IP , protocol) triplet). Of course, 
reduction in this parameter may also increase packet loss. 

Yet another possible defense for name servers, is to al- 
ways add a random RR to any packet over certain size 
(i.e., which may be fragmented). A simple type A re- 
source record, containing random IP address for some 
fictitious domain name, would suffice. The TTL of such 
an RR should be set to zero to prevent the resolver from 
caching that record. This would prevent the attacker from 
being able to predict and (correctly) adjust the checksum 
value. If there are multiple vulnerable fragments, such a 
random RR should appear in each fragment. 

Finally, we suggest to be careful when deploying the 
proposal in 1 25 36) (for server selection) which recom- 
mends to avoid querying non-responsive servers. Re- 
solvers that do not conform to that recommendation, e.g., 
Bind9, are not vulnerable to our server-pinning attacks. 
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